
Fig. 5-21. Reverse path forwarding. 

packet and a priori knowledge of the subnet diameter, or a list of packets already 
seen per source). 

5.3. CONGESTION CONTROL ALGORITHMS 

In this section we will examine five strategies for controlling congestion. These 
strategies involve allocating resources in advance, allowing packets to be discarded 
when they cannot be processed, restricting the number of packets in the subnet, 
using flow control to avoid congestion, and choking off input when the subnet is 
overloaded. 

53.1. Preallocation of Buffers 

If virtual circuits are used inside the subnet, it is possible to solve the conges- 
tion problem altogether, as follows. When a virtual circuit is set up, the call request 
packet wends its way through the subnet, making table entries as it goes. When, it 
has arrived at the destination, the route to be followed by all subsequent data traffic 
has been determined and entries made in the routing tables of all the intermediate 
IMPs. 

Normally, the call request packet does not reserve any buffer space in the inter- 
mediate IMPs, just table slots. However, a simple modification to the setup algo- 
rithm could have each call request packet reserve one or more data buffers as well. 
If a call request packet arrives at an IMP and all the buffers are already reserved, 
either another route must be found or a "busy signal" must be returned to the 
caller. Even if buffers are not reserved, some aspiring virtual circuits may have to 
be rerouted or rejected for lack of table space, so reserving buffers does not add any 
new problems that were not already there. 

By permanently allocating buffers to each virtual circuit in each IMP, there will 
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-vays be w vJace to st^ i" any incoming packer until it can be forwarded. First con-C 
-icier the case of a siop-and-wait IMP-IMP protocol. One buffer per virtual circuit- 
pir IMP is sufficient for simplex circuits, and one for each direction is sufficient fo r 
full-duplex circuits. When a packet arrives, the acknowledgement is not sent back*.^ 
to the sending IMP until the packet has been forwarded. In effect, an acknowledge-*^, 
ment means that the receiver not only received the packet correctly, but also that it ^ 
has a free buffer and is willing to accept another one. If the IMP-IMP protocol"*^ 
allows multiple outstanding packets, each IMP will have to dedicate a fujj ^ 
window's worth of buffers to each virtual circuit to completely eliminate the possi-' ^ 
bility of congestion. * -. ^ 

When each virtual circuit passing through each IMP has a sufficient amount of 
buffer space dedicated to it, packet switching becomes quite similar to circuit 
switching. In both cases an involved setup procedure is required. In both cases''""" 
substantial resources are permanently allocated to specific connections, whether or *v ; 
not the^e is any traffic. In both cases congestion is impossible because all the - 
resources needed to process the traffic have already been reserved. And in bothCT' 
cases there is a potentially inefficient use of resources, because resources not being '3 
used by the connection to which they are allocated are "nevertheless unavailable to > 
anyone else. " X 

Because dedicating a complete set of buffers to an idle virtual circuit is expen- 
sive, some subnets may use it only where low delay and high bandwidth are essen- 
tial, for example on virtual circuits carrying digitized speech. For virtual circuits 
where low delay is not absolutely essential all the time, a reasonable strategy is to 
associate a timer with each buffer: If the buffer lays idle for too long, it is released, -"1 
to. be reacquired when the next packet arrives. Of course, acquiring a buffer might 
take a while, so packets will have to be forwarded without dedicated buffers until "'3 
Lhe chain of buffers can be set up again. , : . : J 

• * 

5.3,2. Packet Discarding /v 3 

Our second congestion control mechanism is just the opposite of the first ontf - 1 
Instead of reserving all the buffers in advance, nothing is reserved in advance. If a ] E 
packet arrives and there is no place to put it, the IMP simply discards it. If the sub- 
net offers datagram service to the hosts, that is all there is to it: congestion is -f 
resolved by discarding packets at will. If the subnet offers virtual circuit service, a 
copy of the packet must be kept somewhere so that it can be retransmitted later: \.j 
One possibility is for the IMP sending the discarded packet to keep timing out and J 
retransmitting the packet until it is received. Another possibility is for the sending \ 
IMP to give up after a certain number of tries, and require the source IMP to time ;| 
out and start all over again. 

Discarding packets at will can be carried too far. It is clearly stupid in the ^ 
extreme to ignore an incoming packet containing an acknowledgement from a *q- 
neighboring IMP. That acknowledgement would allow the IMP to abandon a by- 
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. n ow-rcceived packet and thus free up a buffer. However, if the IMP has no spare 
C ji'i'.Ti. it cannot acquire any more incoming packets to see if they contain acknow- 
ledgements. The solution is to permanently reserve one buffer per input line to 
allow all incoming packets to be inspected. It is quite legitimate for an IMP to 
examine a newly arrived packet, make use of any piggybacked acknowledgement, 
and then discard the packet anyway. Alternatively, the bearer of good tidings could 
be rewarded by keeping it, using the just freed buffer as the new input buffer. 

If congestion is to be avoided by discarding packets, a rule is needed to tell 
when to keep a packet and when to discard it. Irland (1978) studied this problem 
and came up with a simple, yet effective heuristic for discarding packets. In the 
absence of any explicit rule to the contrary, a single output line might hog all the 
available buffers in an IMP, since they are simply assigned first come, first served. 
Figure 5-22(a) s.hows an IMP with a total of 10 buffers. Three of these are per- 
manently assigned to the input lines. The remaining seven are holding packets 
queued for transmission on one of the output lines. 



Input 
lines 



ChO-D-D-D-CHD- 



-□ 
-□ 



Ouput 
lines 



CHKH> 



Free buffers 
□ □ □ 



(a) 



(b) 



Fig. 5-22. Congestion can be reduced by putting an upper bound on the number of 
buffers queued on an output line. 

Even though two output lines are idle, any incoming packets destined for these 
lines must be discarded because there are no spare buffers. This is obviously 
wasteful. Irland's idea is to limit the number of buffers that may be attached to any 
one output queue. For example, if the limit were set at four, the situation of Fig. 5- 
22(b) would prevail: three unassigned buffers. A newly arrived packet wanting to 
go out on the first output line would be discarded rather than allowing it to increase 
the queue length to five. 

This strategy is not really as drastic as it may appear. After all, that output line 
is already running at maximum capacity. Having seven packets queued instead of 
four will not pump the bits out any faster, but it will allow traffic for the other lines 
to be forwarded immediately, possibly doubling or tripling the output rate of the 
IMP. In any case, the discarded packet will be retransmitted shortly. If the system 
is well tuned, it will even be retransmitted before the queue empties, so its initial 
rejection will not even be noticed. 

Irland studied several different algorithms for determining maximum queue 
length, m, for an IMP with k buffers (buffers permanendy dedicated for input do 
not count). The "uncontrolled case is m = k. If there are s output lines, the case 
m = k/s effectively means that each buffer is dedicated to a given output line. No 
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line !r ,ay borrow even one buffer from an idle line, ever. Intuitively this k n 
efliuem, and the study bears this out. ' 15 not 

It tums out that the optimal value of m is a complicated function of the m M " 
traffic. Although the IMP could attempt to measure its traffic nd com to 
adjust m. if the traffic were bursty, this probably would not work well Z ' 
however, discover a simple rule of thumb that usually gives eood but no. nn 
^rf_e ,=,/V7. For ^example, for seven pVol bXs^d 2,7 ^ 
m = 7/V3, so 4 buffers would be allocated. • s> 

A related idea, due to Kamoun (1976). directly prevents any line or lines from ' 
starving: a minimum number of buffers is dedicated to each line If there i< 
traffic, the empty buffers are reserved. Irland's method can be comotd wi h ° 

Tn?APp S AWT aVing I m5nimUm Md 3 maximUm nUmber of buffers for each line • 
The ARPANET uses this method. • 

Although discarding packets is easy, it has some disadvantages. Chief among " 
£ese is the extra bandwidth needed for the duplicates. If the probability of a pack"? 
being discarded ,s p the expected number of remissions before it is" accepted 
1/(1 -p). A related issue ,s how long the timeout interval should be. If it is too 
short, duplicates will be generated when they are not needed, making the conges- 
tion worse. If it is too long, the delay will suffer. 8 

One way to minimize the amount of bandwidth wasted on the retransmission of 
discarded packets is to systematically discard packets mat have not yet traveled f ar 
and hence do not represent a large investment in resources. The limiting case of 

it l?*fiV«° d l CZXd P3CketS fr ° m h0sts » P«fe«ncc to d s Id • 

ng transit traffic^ For example, IMPs could refuse or discard new packets from 

^£ hosts whenever the number of buffers tied up by new packets (or Z 
packets) exceeds some threshold. ; 



5.3.3. Isarithmic Congestion Control 



a nnS"f f Sti ° n ^n" Wh£n t0 ° man y P^kets in the subnet. A direct ! 

approach to controlling it IS to limit the number of packets in the subnet. Davie's < 

( l y II) proposed a method that enforces precisely such a limit H 
In this method, called isarithmic because it keeps the number of packets con-^ 

stam, there exist permits, which circulate about within the subnet. Whenever an 1 

7nHA W T 10 * 2 PaClCet jUSt giVCn t0 U by itS h0SU ir must to a permit ■ 
and destroy it. When the destination IMP finally removes the packet from ihVsub- 

net it regenerates the permit. These simple rules ensure that the number of packets r 

in the subnet will never exceed the number of permits iniually present ' ' 

However, this method has some problems. First, although it does guarantee that ; 

the subnet as a whole will never become congested, it does not guarantee that a r 

given IMP will not suddenly be swamped with packets. S ua ^ee "»t , 

Second, how to distribute the permits is far from obvious. To prevent a newlv ■ 

generated packet from suffering a long delay while the local IMP tries to scout up a ; 
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permit, the permits must be uniformly distributed, so that every IMP has some. On 
aie other hand, to permit high-bandwidth file transfer, it is undesirable for the send- 
ing IMP to have to go hunting all over the place to find enough permits. It would 
be nicer if they were all centralized, so that requests for substantial numbers could 
be honored quickly. Some compromise must be found, such as having a maximum 
number of permits that may be present at any IMP, with excess permits required to 
hunt for an IMP with space. Note that the random walk of the excess permits itself 
puts a load on the subnet. 

Third, and by no means least, if permits ever get destroyed for any reason, (e.g., 
transmission errors, malfunctioning IMPs, being discarded by a congested IMP), 
the carrying capacity of the network will be forever reduced. There is no easy way 
to find out how many permits still exist while the network is running. 

5.3.4. Flow Control 

Some networks (notably the ARPANET) have attempted to use flow control 
mechanisms to eliminate congestion. Although flow control schemes can be used 
by the transport layer to keep one host from saturating another, and flow control 
schemes can be used to prevent one IMP from saturating its neighbors, it is difficult 
to control the total amount of traffic in the network using end-to-ehd flow control 
ruies. Still, if the hosts are forced to stop transmitting due to strict flow control 
rules, the subnet will not be as heavily loaded. 

Flow control cannot really solve congestion problems for a good reason: com- 
puter traffic is bursty. Most of the time an interactive user sits at his tenminal 
scratching his head, but once in a while he may want to scan a large file. The 
potential peak traffic is vastly higher than the mean rate. Any flow control scheme 
which is adjusted so as to restrict each user to the mean rate wilj provide bad ser- 
vice when the user wants a burst of traffic. On the other hand, if the flow control 
limit is set high enough to permit the peak traffic to get through, it has little value as 
congestion control when several users demand the peak at once. .(If half the people 
in the world suddenly picked up their telephones to call the other half, there would 
be a lot of busy signals; the telephone system is also designed for average traffic, 
not worst case.) 

When flow control is used in an attempt to quench congestion, it can apply to 
the. traffic between pairs of: 

1. User processes (e.g., one outstanding message per virtual circuit). 

2. Hosts, irrespective of the number of virtual circuits open. 

3. Source and destination IMPs, without regard to hosts. 

In addition, the number of virtual circuits open can be restricted. 
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Choke F:\c\jts q 

Although limiting the volume of traffic between each pair of IMPs or hosts m ' 
indirectly alleviate congestion it does so at the price of potentially reducir? ~~ 
throughput even when there is no threat of congestion. What is really needed is 
mechanism that is triggered only when the system is congested. " / ■}. 

One way is to have -:ach IMP monitor the percent utilization of each of its out ' 
put lines. Associated with each line is a real variable, u, whose value between 0 0 ~ 
and 1 .0, reflects the recent utilization of that line. To maintain a good estimate of L 
a sample of the instantaneous line utilization, /(either 0 or 1). can be made periodi' -1 
cally and u updated according to 

- - ... . v " 

"new = <2"old + 0 -a)f "3 

* _ 

where the constant a determines how fast the IMP forgets recent history ' ' 

Whenever u moves above the threshold, the output line enters a " warning' 'C 
state. Each newly arriving packet is checked to see if its output line is in warning * 
state. If so, the IMP sends a choke packet back to the source host, giving it the "* 
destination found in the packet. The packet itself is tagged (a header bit is rumed S 
on) so that it will not generate any more choke packets later, and is forwarded in 
the usual way. 

When the source host gets the choke packet, it is required to reduce the traffic § 
sent to the specified destination by X percent. Since other packets- aimed at the 
same destination are probably already under way and will generate yet more choke & 
packets, the host should ignore choke packets referring to that destination for a ^ 
fixed time interval. After that period has expired, the host listens for more choke i - 
packets for another interval. If one arrives, the line is still congested, so the host 
reduces the flow still more and begins ignoring choke packets again. If no choke 
packets arnve dunng the listening period, the host may increase the flow again =2 
The feedback implicit in this protocol should prevent congestion, yet not throttle 
any flow unless trouble occurs. . -j 

Several variations on this congestion control algorithm have been proposed. 3 
ror one, the IMPs could maintain two critical levels. Above the first level choke- --=-1 
packets are sent back. Above the second, incoming traffic is just discarded the 
theory being that the host has probably been warned already. Without extensive j 
tables it is difficult for the IMP to know which hosts have been warned recendy ~ 
about which destinations, and which hosts have not. 

Another variation is to use queue lengths instead of line utilization as the trigger 
signal. The same exponential weighting can be used with this metric as with u°of 
course. Yet another possibility is to have the IMPs propagate congestion informa- 
tion along with routing information, so that the trigger is not based on only one 
LMPs observations, but on the fact that somewhere along the path there is a 
bottleneck. By propagating congestion information around the subnet, choke 
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packets can be sent earlier, before too many more packets are under way thnc 
preventing congestion from building up. y ' thus 

5.3.6. Deadlocks 

The ultimate congestion is a deadlock, also caJled' a lockuo The fire txxd 
not proceed until the second IMP does something InTZ selnd up 
proceed because it is waiting for the first IMP to !o To^inl bL^pThT 
ground to a complete halt and will stay that way torevzV r?^ u C 
sidered a desirable property to have in your network " ^ ^ C ° n " 

^^^^ 

involved in the lockup. wiccuveiy blocked, including those not 
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Fig. 5-23. Store-and-fonvard loc5rjp. ( a ) Direct (b) Indirect. 



or adjacem IMP, The gr aph Z L S ^TZ^ ^ ^ ^ 
from buffer ,o buffer a,o„ g che a,c S of*, graph, ,nen no /ead.^s c lr, oceu" 



THE NETWORK LAYER 



CHAP. 5 



' a simple example of their method, consider a subnet with /V IMPs in which 
tiu- io.igest route from any source to any destination is of length M hops. Each IMP 
mods M + 1 buffers, numbered from 0 to M. The buffer graph is now constructed 
by drawing an arc from buffer / in each node to buffer /' + 1 in each of the adjacent 
nodes. The. legal routes from buffer / at IMP A are those to a buffer labeled / + 1 at 
IMPs adjacent to A, and then to a buffer labeled / + 2 at IMPs two hops from A, etc. 

A packet from a host can only be admitted to the subnet if buffer 0 at the source 
IMP is empty. Once admitted, this packet can only move to a buffer labeled 1 in an 
adjacent IMP, and so on, untiJ either it reaches its destination and is removed from 
the subnet, or it reaches a buffer labeled M, in which case it is discarded. (If M is 
chosen longer than the longest route, then only looping packets will be discarded.) 
A packet in buffer i in some IMP may only be moved if buffer / + 1 in the IMP 
chosen by the routing algorithm is free. Note that numbering the buffers does not 
restrict the choice of routing algorithm, which can be static or dynamic. 

To see that this algorithm is deadlock free, consider the state of all buffers 
labeled M at some instant. Each buffer is in one of three states: empty, holding a 
packet destined for a local host, or holding a packet for a distant host. In the second 
case the packet can be delivered, in the third case the packet is looping and must be 
dropped. In all three cases the buffer can be made free. Consequently, all the pack- 
ets in buffers labeled M - 1 can now be moved forward, one at a time, to be 
delivered or discarded. Once all the buffers labeled AY - 1 are free, the packets in 
buffers labeled M - 2 can be moved forward and delivered or discarded. Eventu- 
ally, all packets can be delivered or discarded. If the routing algorithm guarantees 
that packets cannot loop, then M can be set to the longest path length, and all pack- 
ets will be correctly delivered with no discards and no deadlocks. 

Merlin and Schweitzer have also presented many improvements to this simple 
strategy to reduce the number of buffers needed and to improve* the performance. 
For example, "a packet that has already made / hops (i.e., is currently in a buffer 
labeled i), can be put in any available higher numbered buffer at the next hop, not 
just in buffer i + 1. As long as the sequence of buffer numbers is monotonicaJly 
increasing, there can be no deadlocks. 

Although this algorithm avoids deadlock completely, it has the disadvantage 
that under normal qircumstances many buffers will be wasted due to lack of the 
appropriate packets. Furthermore, lines will be frequently idle because the buffer 
that the packet at the head of the queue happens to. need is not available at the 
moment. 

A completely different deadlock prevention algorithm that does not have these 
properties has been published by Blazewicz et al. (1987a). In their algorithm, each 
packet bears a globally unique limestamp. This stamp contains the lime the packet 
was created in the high-order bits and the machine number in the low-order bits. It 
is not essential that all the clocks be synchronized, although the algorithm tends to 
give, fairer service if the clocks are not too far apart. 

The algorithm requires each LMP to reserve one 'buffer per input line as 3 
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special receive buffer. All the other buffers can be used for holding packets in tran- 
sit. These packets are queued in timestamp order in a separate queue for each out- 
put line, as illustrated in Fig. 5-24. In the absence of any deadlock prevention algo- 
rithm, the three IMPs in Fig. 5-24 would be deadlocked because although each one 
can receive a packet from its neighbors, it has nowhere to store it while the packet 
waits its turn for the next hop. 

One of these 

Find oldest packet , will have to 




Fig. 5-24. Three potentially deadlocked IMPs. 

The essence of the algorithm is that it makes a distinction between three condi- 
tions. In all three cases we assume that A has an important packet that it wants to 
send to B. The conditions are: 

1. B has a free buffer. 

2. B does not have a free buffer, but it does have a packet- for A. 

3. B has neither a free buffer nor a packet for A. 

In case 1, A just sends its packet. In case 2, A and B exchange packets, so that the 
newly arrived packet can be put in the buffer just freed by the packet going "the 
other way. In case 3, B is forced to choose a packet not destined for A (preferably, 
one that is at least going in the same general direction as A) and this packet -'is 
exchanged with ^'as in case 2. 

Now we can explain the algorithm and prove that it is deadlock free. Whenever 
a line goes idle, the two IMPs at the ends of it exchange control packets giving the 
timestamp of its oldest packet that wants to use the line. The one with the lowest 
number (oldest packet) wins and that packet is sent, even if case 3 applies and the 
losing IMP is forced to send another packet in the wrong direction to free up buffer 
space for the winner. At any instant, one packet in the subnet has the honor of 
being the oldest. This packet will always come on top in any IMP-IMP'discussion 
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•out n^e, -o this picke' will make nonstop progress to its destination. As soon as 
U has been delivered, some other packet becomes the oldest, and it can then 
■•.rocced unobstructed to its destination. As time marches on, every packet eventu- 
ally becomes the oldest and is delivered. 

Two criticisms can be leveled at this algorithm. First, a young packet may be 
sent far out of its way before it acquires enough seniority to start consistently win- 
ning the IMP -IMP timestamp comparisons. However, in practice, case 3 only 
c-curs when the subnet is heavily loaded (all buffers full). If an IMP has, say, 3 or 
4 outgoing lines and 20 to 50 full buffers, chances are that none of the outgoing 
queues will be empty, so that the losing IMP will nearly 'always be able to find a 
good packet to exchange with the winner. 

The second criticism has to do with clock synchronization. If one IMP's clock 
is a few seconds ahead of all the others, its packets will be at a competitive disad- 
vantage when timestamps are compared. Still, within a few seconds, its packets 
will get delivered, so the condition is annoying but not fatal. If each pair of adja- 
cent IMPs periodically exchanges clock values, each IMP can then set its time to 
the average of its neighbor's times. In this way, no clock can get very far out of 
step with the rest. 

Store-and-forward lockups are not the only kind of deadlocks that plague the 
subnet. Consider the situation of an IMP with 20 buffers and lines to four other 
IMPs, as shown in Fig. 5-25. Four of the buffers are dedicated to the four input 
lines, to help alleviate congestion. Assume that a sliding window protocol is being 
used, with window size seven. Further, assume that packets are accepted out of 
order by the IMP, but must be delivered to the host in order. At the time of the 
snapshot, four virtual circuits, 0, 1,2, and 3, are open between the host and other 
hosts. 

Rather than dedicate a full window load of buffers to each open virtual circuit, 
buffers are simply assigned on a first come, first served basis. As soon as the next 
sequence number expected by the host becomes available, that -packet is passed to 
the host (with each virtual circuit independent of all the others). However higher 
number packets within the window are buffered in the usual way. 

In Fig. 5-25 v and s indicate the virtual circuit and sequence number of each 
packet, respectively. The host is waiting for sequence number 0 on all four virtual 
circuits, but none of them have arrived undamaged yet. Nevertheless, all the 
buffers are occupied. 

If packet 0 should arrive, it would have to be discarded due to lack of buffer 
space. As a result, no more packets can be passed to the host and no buffers freed. 
This deadlock occurred in the ARPANET in a slightly different form, and was 
called reassembly lockup. 

In the ARPANET there are multipacket messages (i.e., messages too large to fit 
into a single packet). By allowing hosts to pass relatively large chunks of informa- 
tion to the LMPs in a single transfer, the number of host interrupts could be reduced. 
The sending IMP splits multipacket messages into individual packets and sends 
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Fig. 5-25. Reassembly lockup. 

each one separately. The destination IMP must put all the pieces together before 
passing the reassembled message to the host. If pieces of several muhipacket mes- 
sages have managed to commandeer all the available buffer space in the destinauon 
IMP the missing pieces will have to be rejected and the IMP (and host) will be 
deadlocked. 

The ARPANET solution is to have the source IMP ask the destination IMP per- 
mission to send a muhipacket message. The destination IMP ihen dedicates enough 
buffers to reassemble the full message before telling the source to go ahead The 
sliding wmdow version of the deadlock can only be prevented by dedicating a full 
window s worth of buffers to each open virtual circuit. The reason this strategy is 
more attractive in the ARPANET case is that there most (96%) messages are single 
packet, not muhipacket, whereas in the sliding window case, in effect, all messages 
are muhipacket/ 5 

' Two other problems discovered in the ARPANET are worth mentioning here 
Both were caused by malfunctioning IMPs. All of a sudden, one IMP announced 
that u had zero delay to all other IMPs in the entire subnet. The adaptive routing 
aJgonthm spread the good news far and wide. The other IMPs were ecstatic 
Wuhm a few seconds, practically all of the traffic in the entire subnet was headed 
toward the only IMP that was not working properly. Although not a deadlock, this 
certainly brought the whole network to a grinding halt. 

other problem was also caused by a failing memory. One fine day the 
Aberdeen IMP (on the East Coast) decided that it was the UCLA IMP (on the West 
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Coast) The ccr.scquerres of this case of mistaken idcntiiy can be easily imagined 
especially for the UCLA and Aberdeen hosts. smec^. 

The fix applied to the IMP software was to have each IMP periodically commit* 
a software checksum of its own code and tables, in hope of discovering failW 
memory words, such as those that caused the above problems. Nevertheless *f 
n?. S g,ng question of how you prevent one bad IMP from bringing the whole ne t 
work down remains. One of the arguments in favor of computer networking is Z 
higher reliability can be achieved so: if one machine goes down, there Ire UU 
plenty of others around. However, if a single failure at one site often pollutes * 
entire nationwide (or worldwide) system, there may be no advantage at all 

An exhaustive catalog of other network deadlocks and possible solutions m 
them ls glven by Lai n982) . Gther dead]ock event . on P soluiions to 

Blazewicz et al. (1987b), and Gopal (1985). mussed by 

5.4. INTERNETWORKING O 

Up until now we have implicitly assumed that there is a single homogeneous 
network, with each machine using the same protocol in each layer Unfortunately 

20 S 0(^^NA 13 i§tiC - Many diff£rem netWork " exist - More 

20.000 SNA networks more than 2000 DECNET networks, and uncountably man^ 

^ V^T ^ » da «y option all over the world (Green" 

ttnlv r 1S T ^r 5 ' WhCn " bccomes 10 interconnect two or more 

networks together to form an internet. Additional detail can be found in (Burg et 
al. 1984; Hindcn et al. 1983; Israel and Weissberger, 1987- Poste 1980- 
Schneidewind 1983; Stallings 1987; and Weissberger and Israel 1987) 

Enormous controversy exists about the question of whether today's abundance 
of network types is a temporary condition that will go away as soon as everyone 
reahzes how wonderful OSI is, or whether it is an inevitable, but pendent featu A 
of the world that is here to stay. We believe that a variety of deferent networks 
will always be around for the following reasons. First of Z 1, me instaJled bTse of 

new SNA /vT 5 * t * ^ ^ *"* BM is Sti11 sellin S 

new SNA systems. Most UNIX shops run TCP/IP. LANs are rarely OSI This 

S?cSL^TJ or iT n be ? use - not aJI vendors perceive il in the * imerest for 

their customers to be able to easily migrate to another vendor's system 

Second, as computers and networks get cheaper, the place where decisions set 
made moves downward. Many companies have a policy to the effect Tat Pur- 
chases costing over a million dollars have to be approved by top management dot- 
cnases costing over 100,000 dollars have to be approved by middle manTgemenl 
out purchases under 100,000 dollars can be made by department heads without anv 
h.gher approval. Th 1S can easily lead to the accounting department installing an 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



□ REFERENCE(S) OR EXHD3IT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: ! 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




[LACK BORDERS 




LINES OR MARKS ON ORIGINAL DOCUMENT 



